Inconsistency Tolerance across Enterprise Solutions

As every information system becomes connected to every other information system, they form the so-called "information utility". This is the domain in which contemporary distributed systems have to evolve. New applications have to be evolved on this platform of existing systems that may hold inconsistent information. Consequently, solutions have to be able work in a world of only partially correct information. In this paper, we discuss means whereby architects, designers and engineers are able, in this context of information inconsistency, to develop new business solutions and reason about their validity. In particular we describe the properties of inter-enterprise system architectures for applications working with partially replicated and partially consistent information. These must be able to operate under reversible assumptions and to undo operations as a consequence of reversing assumptions. We have developed exemplary architectures that exhibit these properties, used them to investigate the concept of inconsistency-tolerant components and begun to devise methods of building inter-enterprise applications from such components. This approach, we conjecture, makes reasoning about the validity of proposed inter-enterprise scale solutions more straightforward and thus increases the speed with which new solutions can be deployed. We are evaluating these ideas now, by building, along with our industrial collaborators, realistic enterprise-scale demonstrations in the domains of Finance and Defence. 1: Background The growth of the everything-connected-toeverything-else information utility arises now because of the ubiquity of distributed computing, in particular the internet, both within an organisation and between organisations [12]. Indeed, the fact that the global internet and intranets of individual companies are based on the same technologies, has made business-to-business ecommerce a growing reality [3]. The problem this creates is that we have to evolve business systems from existing components [10], where the information that they integrate comes from multiple sources and this information is often inconsistent across these sources. The sheer scale of the systems that must be integrated in order to achieve business objectives exacerbates the problem [1]. It is on this scale that we need to be able to reason about the validity of solutions. Overall, we need to maintain known consistency properties of partially replicated information in order to support continuous potential-for-change and evolution. This is not an uncommon circumstance in Transaction Processing (TP) systems, but TP systems are typically very tightly coupled and consequently do not allow easy evolution. They implement strong consistency through transactions using protocols for distributed TP such as two-phase-commit. We need to challenge the appropriateness of two-phase-commit and other quasisynchronous transaction models, partly because of the consequences for reliability and performance, but in particular in the context of the information utility, because of the reality that data sources will frequently be inconsistent with each other. Hence the move to more loosely-coupled application systems integration, with technologies based on relatively loosely-coupled technologies derived from XMLmessaging. Such approaches introduce asynchronous communication with concurrency, which adds a difficult temporal dimension into reasoning about information consistency [5, 9]. Enterprise Application Integration (EAI) tools provide mechanism(s) for integration but there is little formal underpinning. Reasoning about validity of a proposed solution is largely left to the intuition of the designer. In order to improve this situation, we need to be able to: • Categorise component application system properties in terms of information storage & access • Reason about adding new components to existing configurations • Reason about migration of information (and functions) • Reason about consistent derivations of information • Reason about the consistency properties visible to an observer with access to several components These requirements lead us to consider the properties that an enterprise system must have if it is to be very flexible (allowing, for example, enterprise-level plug-andplay) [6, 10]. Before we enumerate those properties and discuss architectures which support them, we will look at a simple example from the domain which interests us.